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ABSTBACT 


This  thesis  describes  the  performance-measurement  ex p-ri- 
ments  designed  for  a  number  of  backend,  relational  database 
machine  configtir atiocs.  An  in-depth  study  of  the  tests  and 
results  cf  the  t«io  relational  operations,  namely,  sele<rior. 
and  prolection,  on  a  specific  configuration  is  presented. 
In  addition ,tasts  are  made  on  the  ordering  capabilities  and 
performance  of  the  machine  configuration.  The  goal  of  the 
work  is  to  lead  to  a  development  for  a  machine-independent 
methodology  for  benchmarking  the  selection  and  projection 
operations  and  on  ordering  capabilities  of  database 
machines. 


3 


TABLE  OP  CONTENTS 


I.  INTRODUCT  ION . 8 

A.  BENCHMARK ING  DATABASE  MACHINES . 3 

1.  A  Definition . 8 

2.  Database  Sachin?  Benchaarks . 9 

3.  Objectives . 10 

B.  THE  BENCHMARKING  ENVIRONMENT . 11 

1.  The  Hcst  .  .  .  .  * . 12 


III. 


2.  The  Hcst  Interface . 12 

3.  Machine  Configurations . 13 

C.  THE  BENCHMARKED  MACHINE . 14 

1.  Modular  Design . 14 

2.  Technology  and  Functionality  of  Modules  .  15 

THE  DATABASE . 18 

A.  THE  USE  OF  SYNTHETIC  DATA . 18 

B.  GENERATION  OF  THE  SYNTHESIZED  DATA . 19 

THE  Q0E3Y  LANGUAGE . 23 

A.  SYNTAX  AND  SEMANTICS . 24 

B.  TEST  QUERIES . 25 

1.  Tieing  Considerations . 26 

2.  Objectives . 27 

PERFORMANCE  EVALUATION  OF  THE  SELECTION  OPERATION  28 


A.  DEFINITION  OF  A  SELECTION 


B.  SELECTIONS  IN  THE  QUERY  LANGUAGE . 28 

C.  AN  ENVIRONMENT  FOR  THE  MEASUREMENTS . 29 

D.  SELECTION  MEASUREMENTS . 30 


1.  The  Percentage  of  Selection . 30 

2.  Effects  of  Clustarei  and  Non-Clast ered 

Indiclss . 33 


.'.iiTAra'i 


» t« .  IP.  IV  j .  f.  1«. P  V.TTT.TT?  ?  •  J  7’.  V  w « I 


3.  Effects  of  Data  Compression  on  Selection 


Queries . 35 

4.  Effects  of  Ordering  and  Randomizing  the 

Database  Entries . 39 

B.  CONCLUSIONS . 42 

f.  PERFORMANCE  EVALUATION  OF  PROJECTION  OPERATION  .  .  45 

A.  DEFINITION  OF  A  PROJECTION . 45 

B.  PROJECTIONS  IN  THE  QUERY  LANGUAGE . 45 

C.  AN  ENVIRONMENT  FOR  THE  MEASUREMENTS . 46 

D.  PROJECTION  MEASUREMENTS . 47 

1.  Percentage  of  Projections  on  Non-Key 

Attributes . 47 

2.  Comparison  of  the  Equivalent  Queries  cn 

Selection . 52 

E.  CONCLUSIONS . 59 

VI.  CCMCLUDIHG  REMARKS . 61 

A.  OVERALL  OBSERVATIONS  OF  THE  MACHINE 

PERFORMANCE . 61 

B.  DATABASE  AND  MACHINE  LIMITATIONS . 62 

C.  RECOMMENDATIONS  FOR  FUTURE  BENCHMARKING 

EFFORTS . 6  3 

LIST  OF  REFERENCES . 65 

INITIAL  DISTRIBUTION  LIST . 66 


Va'. 


LIST  OF  FIGURES 


1.1  Ihe  RDH-1100  Relational  Database  computer  ...  15 

2.1  Tuple  Tea  plates . 21 

4.1  Sieple  Selects  with  no  Indicias . 31 

4.2  5%-Selects  with  Eon-Clustered  Index  on  P5  and 

P10 . 32 

4.3  Ordered  Retrieves  with  Indicies  on  KEY . 34 

4.4  Retrieves  with  and  without  Indicies . 35 

4.5  Speed  leproveaent  using  Mon-Clustered  Index  on 

E5  and  P10 . 37 

4.6  Effects  of  Data  Coepression . 33 

4.7  Effects  of  Ordering  on  the  Rasponse  Tine  ....  40 

4.8  k  Comparison  of  Host's  and  Backend's  Ordering 

Capability . 41 

4.9  Effects  of  Ordering  on  Ordered  and  Random 

Relations . 43 

5.1  251  Projections  on  51  Selections . 43 

5.2  25*  Projections  on  10*  Selections . 49 

5.3  50*  Projections  on  5*  Selections . 50 

5.4  75*  Projections  on  5*  Selections . 51 

5.5  Effects  of  Differing  Projection  Percentages  for 

200-byte  Tuples . 53 

5.6  Effects  of  Differing  Projectin  Percentages  for 

1000-byte  Tuples . 54 

5.7  Comparison  cf  Projection  and  Selection  for 

100-byte  Tuples . 55 

5.8  Coaparison  of  Projection  and  Selection  for 

200-byte  Tuples . 56 

5.9  Coaparison  cf  Projection  and  selection  for 

1000-byte  Tuples . 57 

5.10  Coaparison  cf  Projection  and  Selection  for 

2000-byte  Tuples  . . 58 


6 


'  \*yv 'v, 


ACKHO  WLEDGEBBNT 


The  experiaents  described  in  this  thesis  are  the  results 
of  the  coordinated  efforts  of  many  individuals.  Foremost  of 
these  individuals  is  certainly  as.  Paula  Strawser  of  The 
Ohio  State  University  and  the  Naval  Postgraduate  school. 
Hs.  Strawser's  diligence,  dedication,  and  guidance  have 
proven  invaluable  in  both  the  research  prior  tc  and  subse¬ 
quent  preparation  of  this  thesis. 

Likewise,  Hs.  Doris  Hleczko  and  her  staff  at  th®  Data 
Processing  Service  Canter  Best  at  Point  Hugu,  California, 
have  provided  auch  assistance,  and  they  have  proven  flexible 
enough  tc  accomodate  our  soaetiaes  inflexible  requirements. 
Gratitude  is  also  expressed  to  Hr.  Ben  Torres  and  his  staff 
at  the  Ccaputer  Operations  Center  at  Point  Hugu. 

finally,  to  Coaaander  Toa  Pigoski  of  the  Naval  Security 
Group  Coaaand  is  offered  a  special  thanks  for  his  continued 
support  in  providing  the  necessary  assistance  both  tc  keep 
this  project  going  and  to  enable  the  results  cf  this 
research  to  be  presented  at  the  International  workshop  on 
Database  Hachines  in  Hunich,  Septeaber,  1933. 


7 


I.  IHTBODOCTIOH 


1.  BIMCHB1BKZHG  DATAEASE  HACHIIES 

Benchmarks  have  long  been  a  means  for  making  effective 
comparisons  of  differing  hardware  configurations  and  hard¬ 
ware  architectures.  ks  early  as  1970  instruction  mixes  were 
formed  and  tested  over  varying  configurations  to  provide  a 
means  cf  comparison  between  installations.  The  early  works 
included  the  Gibson  [Bef.  1],  and  ?lynn  [Ref.  2],  mixes 
which  consisted  of  machine  instructions  ordered  by  instruc¬ 
tion  class.  The  Gibson  mix  was  based  on  data  collected  from 
13 H  7090  installations,  while  the  Flynn  mix  used  programs 
run  at  IBH  System/360  installations.  There  has  been  some 
work  done  with  similar  approaches  at  the  language  level, 
predominantly  the  work  of  Knuth  [Bef.  3],  who  used  a  mix  of 
Fortran  statements  to  obtain  his  benchmark  parameters.  all 
these  approaches  involved  the  running  of  some  standardized 
mix  of  instructions,  either  machine  instructions  or  instruc¬ 
tions  in  some  high-level  language.  They  used  the 
experimental  results  from  these  runs  to  conduct  an  analysis 
of  the  computer  system  performance. 

i.  i  Esiislslaa 

Benchmarking  is  a  term  used  throughout  the  industry 
in  a  myriad  of  differing  contexts.  In  each  case  *he  ulti¬ 
mate  goal  is  to  make  an  independent  measure  or  rel*vent 
comparison  of  machine  capabilities.  These  comparisons  or 
measures  could  be  anything  from  the  throughput  to  the  speed 
of  calculations  by  a  certain  internal  component,  but  in  the 
final  analysis  seme  measure  or  evaluation  of  performance  is 
desired. 


There  are  many  different  ways  of  evaluating  machine 
performance.  Many  manufacturers  provide  the  capability  of 
attaching  aonitoring  systeas  *o  their  equipment.  These  may 
be  either  hardware  monitors,  which  physically  sense  the 
action  occuring  in  the  system  and  lceep  statistical  records, 
cr  they  nay  be  software  monitors  which  attempt  tc  perform 
the  saae  function  with  software  hooks  that  keep  track  of  the 
system  operation  and  give  the  operator  a  statistical 
analysis  of  the  machine  action  and  performance.  Software 
monitors  have  the  disadvantage  of  using  a  good  deal  of  the 
system  time  just  for  their  own  operation.  Though  hardware 
monitors  do  not  suffer  from  this  disadvantage,  they  require 
the  wiring  of  the  monitor  system  into  the  hardware.  The 
biggest  disadvantage  to  these  types  of  measurements, 
however,  is  the  inability  tc  make  comparisons  on  differing 
machine  configurations  and  between  different  manufacturers. 
Eenchmarks  attempt  to  solve  this  problem  by  forming  some 
standardized  testing  methodology  that  is  easily  transpor¬ 
table  from  one  machine  to  another  machine.  Mo  s* 

importantly,  the  measurements  made  must  be  r®lev=r.t  regard¬ 
less  of  the  aachines  benchmarked  and  give  an  accurate  means 
cf  comparison  between  these  aachines. 

Therefore,  benchmarks  are  defined  to  be  certain  sets 
cf  instructions  that  will  test  all  the  capabilities  of  a 
machine  and  yield  sose  generic  set  of  data  that  will  give  an 
accurate  seasure  of  that  sachine  in  its  tested  configura¬ 
tion.  This  data  will  then  give  the  observer  specific 
guidelines  for  making  relevant  and  general  comparisons  with 
similar  machine^  and  configurations. 

2.  Database  Machine  Benchmarks 

With  the  advent  of  special-purpose  database  aachines 
and  backend  database  machines,  a  new  field  of  application 
for  benchmarks  exists.  Previously,  benchmark  routines  have 


been  used  exclusively  for  the  testing  end  performance  evalu¬ 
ation  of  large  general-purpose  mainframes.  with  the  proli¬ 
feration  of  backend  processors  to  unload  specialized  tasks 
froe  the  mainframe,  these  benchmarks  have  baen  ineffective, 
because  the  computer  systems  capabilities  of  performing  the 
specialized  tasks  are  not  benchmarked.  Our  primary  concern 
is  with  the  benchmarking  of  specialized  backends  known  as 
database  machines.  In  this  context  we  mean  a  specialized 
processor  externally  linked  to  a  mainframe,  with  its  own 
special-purpcse  hardware  and  software  for  database  manage¬ 
ment.  Eackend  refers  to  this  externally-linked  and 
specially-built  machine. 

3 .  Objectives 

lit  present  the  backend  database  machine  is  ir.  its 
infancy  in  the  commercial  marketplace.  Nevertheless,  the 
database  system  is  extensively  utilized  in  various  forms  and 
for  different  tasks,  exclusively  in  some  software  configura¬ 
tion  operating  on  a  large  general-purpose  machine.  In  order 
to  provide  effective  database  functions  the  software-laden 
database  system  consumes  a  great  deal  of  the  mainframe's 
resources  which  severly  limits  the  usefulness  of  the 
mainframe  for  other  functions. 

This  has  started  a  trend  towards  the  backend  data¬ 
base  machine,  one  that  can  reduce  the  time  the  host  spends 
in  searching  and  updating  data  in  response  to  user  queries. 
This  greatly  increases  the  ultimate  usefulness  of  the  host, 
since  these  backend  database  machines  are  only  a  small  frac¬ 
tion  of  the  total  system  cost.  The  database  machines  now  on 
the  market  have  been  implemented  using  microprocessor  tech¬ 
nology  rather  than  fully -specialized  hardware,  thereby 
keeping  their  costs  down.  is  the  market  expands  and  more 
progress  is  made  in  VLSI  technology,  we  can  expect  tc  see 
more  specialized  hardware  at  even  lower  cost. 


Cur  objectivs  hers  is  to  develop  seme  basic  testing 
procedures  tc  benchmark  relational  database  machines.  This 
thesis  also  gives  account  of  test  results  performed  or.  a 
specific  backend  database  machine,  the  RDM-1100,  and  i*s 
various  configurations.  If  is  limited  to  the  results  of 
test  queries  in  the  operations  of  selection  and  projection 
and  ordering  capabilities.  In  addition  *c  this  thesis, 
there  are  three  other  theses,  [Refs.  4,5,6],  which  describe 
in  detail  the  test  procedures  and  results  of  doir.  opera¬ 
tions,  the  generation  of  the  databases  used  in  the 
experiments,  and  the  other  test  procedures  and  results.  The 
ultimate  goal  of  the  entire  project  is  tc  develop  and  iden¬ 
tify  some  sets  of  queries  that  can  be  used  ir.  evaluating 
database  sachine  performance. 

B.  THE  BENCHHARKIHG  ENYIRO  HMEHT 

Our  primary  emphasis  is  to  evaluate  the  performance  of 
the  systea/machine  under  typical  operating  conditions.  Ir. 
this  sense  a  standardized  workload  model  must  be  developed. 
This  includes  the  use  of  typical  user  queries  (transactions) 
in  addition  to  the  design  of  a  database.  In  terms  of  th* 
database,  we  developed  a  paramater ized  database  generator 
that  will  generate  our  databases  with  attributes  according 
to  a  specified  format  and  with  values  from  well-defined 
domains  according  to  specific  distributions.  Me  chose  this 
approach  so  that  we  could  predict  or  interpret  accurately 
tha  results  of  any  given  query.  More  details  are  given  on 
the  context  and  design  of  the  database  in  Chapter  II. 

Query  streams  are  developed  to  test  the  full  range  of 
possible  user  operations.  All  queries  are  in  forms  of 
selection,  projection,  or  join  operations  as  may  be  made  by 
a  typical  user.  The  actual  query  syntax  ar.d  selection  of 
query  streams  is  discussed  further  ir.  Chapter  III. 


In  addition,  tbs  environment  available  to  us  for  the 
test  tuns  is  very  restricted.  Thera  are  no  hardware  or 
software  probes  available  at  the  time  of  testing,  r.or  any 
statistical  information  on  the  backend  machine.  Our  only 
recourse  is  to  'use  a  built-in  retrieve  function  that  will 
give  a  readout  of  the  database  machine  clock. 
Unfortunately,  the  clock  has  a  low  resolution,  1/60  of  a 
second.  A  system  call  is  executed  to  retrieve  the  time 
before  and  after  each  test  query,  thereby  providing  a  crude 
yet  consistent  time  measure. 

1.  The  Host 

The  actual  testing  is  dene  using  a  ONI  VAC  1100/42 
host  system.  The  system  is  located  at  the  Pacific  Missile 
Test  Center,  Point  Hugu,  California.  The  basic  database 
machine  used  is  the  BDH-1100,  which  is  a  Britton-Lee  IDH-500 
modified  to  run  as  a  tackend  to  UNIVAC  1100  computers  by  the 
Acperif  Ccrp.  of  Chatsworth,  California. 

The  testing  is  done  using  run-stream  gueries  in  an 
interactive  environment.  These  gueries  are  run  either  on 
site  at  Ft.  Hugu,  cr  from  a  remote  terminal  set  up  at  the 
Naval  Postgraduate  School,  Honterey.  Ms  prefer  tc  run  the 
test  queries  in  a  stand-alone,  single-user  mode  in  order  to 
minimize  the  effects  of  workload  variability  of  the  host 
machine.  In  the  event  that  the  queries  are  not  run  stand¬ 
alone,  the  number  of  coincidental  users  is  very  low  and 
little  or  no  difference  is  observed  in  the  measurement  from 
one  run  tc  another. 

2.  £Jie  F}ost  Interface 

The  interface  between  Onivac  and  the  RDH  is  via  a 
word  channel;  the  BEH  is  treated  as  an  I/O  device  by  the 
ONIVAC  mainframe.  The  standard  IDH  device  is  capable  of 
communicating  over  an  8S-23  2  serial  interface  or  an  IEEE-488 
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parallel  interface.  The  communication  board  cf  the  ID!*  at 
Pt.  Hugu  has  been  modified  to  be  compatible  with  the  Or.tvac 
system.  It  supports  tyte/word  channel  interface  with  a  200'K 
byte/seccnd  capacity. 

The  driver  routines  on  the  Onivac  host  handle  the 
parsing  cf  the  user  queries,  and  translate  them  into  '■.h?  IDM 
internal  format.  The  host  also  handles  the  communication 
protocol  with  the  backend  machine.  The  backend,  in  addition 
to  performing  the  necessary  handshakes,  will  perform  the 
required  error  checks  and  cause  the  host  to  retransmit  in 
the  event  that  an  error  is  detected. 

3 .  Machine  Configurations 

The  IDS- 500  system  comes  with  different  amounts  of 
internal  cache  memory,  and  has  an  optional  accelerator 
board.  The  accelerator  is  a  high-speed  processor  designed 
to  perform  certain  common  relational  functions  in  order  to 
increase  the  overall  system  performance.  The  machine  car.  be 
configured  to  hold  1-6  megabytes  of  information.  He  have 
run  tests  on  the  following  configurations: 

(1)  1/2-megabyte  cache  without  accelerator; 

(2)  2-megabyte  cache  with  accelerator; 

(3)  2-megabyte  cache  without  accelerator. 

Th9  first  cf  these  configurations  is  no  longer  marketed. 
The  standard  package  contains  1-megabyte  of  cache  memory  and 
no  accelerator.  In  addition,  the  machine  used  in  our  *ssts 
is  linked  exclusively  to  the  Onivac  1100,  and  is  equipped 
with  only  one  disk  controller,  with  access  to  two 
600-megabyte  disks. 


C.  IBS  EEHCHHABKED  MACHINE 


He  chess  to  restrict  our  work  to  the  IDH-50G,  a  r? la- 
tional  database  aachine.  This  type  of  machine  is  relatively 
new  ou  the  database  market.  Although  it  is  no*  clear  that 
it  will  be  tha  predominant  database  aachine  architecture, 
the  latast  literature  and  current  trends  appear  to  indicate 
that  it  aay  play  an  important  rola,  at  least  in  the  short 
run. 

The  relational  aodel  is  intuitively  easier  to  use  and 
understand  than  ether  database  models,  and  it  appears  that 
it  will  signif leant ly  contribute  to  lower  software  develop¬ 
ment  costs.  Nevertheless,  fully-implemented  seftwar® 
relational  database  management  systems  have  severe  perfor¬ 
mance  problems.  The  high  cost  of  performing  relational 
operations,  most  strikingly  ths  join  and  projection 
operations,  underlies  the  problem. 

lith  the  great  interest  in  the  relational  database 
models  and  the  advances  in  technology  that  permit  the  use  of 
special-purpose  processors  and  backend  systems  tc  perform 
the  majority  of  work,  we  feel  that  the  relational  database 
machine  will  play  an  important  role  in  the  database  manage¬ 
ment  market.  The  Britton-Lee  IDM-5  00  is  one  of  the  first 
machines  to  take  advantage  of  this  technology  and  incorpo¬ 
rate  it  into  a  relational  database  system  which  can  be  used 
as  a  backend  to  a  variety  of  mainframes. 

i  •  sa lias 

The  3rittoa-Lee  IDH-500  is  a  backend  relational 
database  aachine  that  can  be  linked  to  one  or  more  host 
computers.  Aaperif  Corp.  markets  this  system  under  an  CEM 
agreement  as  the  BDH-1100.  Essentially,  the  system  is  a 
Britten-Lee  IDB-500  with  Amperif  providing  the  host  ana 
backend  interface  software  to  communicate  with  the  'Jnivac 
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1100  and  a  host -interface  module.  Figure  1.1  depicts  the 

architecture  of  the  Eritton-Lee  aachine.  Fron  nee  cn  we 
will  use  IDM-500  and  RDM-1100  interchangeably. 

The  backend  is  a  modular,  expandable, 

microprocessor-based  systea  organized  around  a  central  high 
speed  bus.  Each  aodule  is  functionally  oriented. 

2.  Technology  a.jd  Functionality  of  Modules 

The  RDM-1100  is  made  up  of  six  basic  modules  organ¬ 
ized  cn  a  central  high  speed  bus  (  see  Figure  1.1  again  ). 

The  scdules  perform  the  following  functions: 

a.  The  database  processor 

The  database  processor,  a  28000- base d  micropro¬ 
cessor,  supervises  and  manages  all  systea  resources.  This 
processor  executes  most  of  the  software  in  the  systea. 

b.  The  database  accelerator 

The  database  accelerator  (an  optional  processor) 
is  a  high-speed  processor  with  an  instruction  set  specifi¬ 
cally  designed  to  perform  and  optimize  certain  functions. 
It  is  activated  by  the  database  processor  as  appropriate. 
The  accelerator  has  a  three-stage  pipeline  which  executes 
instructicns  at  up  to  10  HIPS.  This  processor  can  initiate 
disk  activity  and  process  data  at  disk  transfer  rates.  The 
accelerator  and  the  RDM  software  are  so  configured  that  the 
majority  of  database  work  is  performed  by  the  accelerator 
under  the  direction  of  the  database  processor. 

c.  The  main  memory 

The  RDM  main  memory,  or  cache  memory,  is 
composed  of  64k-bit  dynamic  RAH  chips.  The  RDM  can  be 
configured  with  from  1-megabyte  to  6-megabytes  of  memory. 
This  memory  is  utilized  for  RDM  system  code,  disk  buffering, 
indices,  and  user  commands. 
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a.  Ths  internal  bus 


The  entire  system  uses  a  common  internal  bus 
system  fcr  inter-processor  cciaunication  and  data  transfer. 

e.  The  dislc/tape  interfaces 

Bie  system  can  be  configured  with  up  tc  4  disk 
controller  modules.  Bach  controller  cat  manage  from  one  tc 
four  disk  drives.  The  disk  controller  moves  data  between 
external  disks  ar.d  the  ROM  Bain  memery.  Ths  disk  controller 
is  designed  tc  work  with  ths  accelerator  which  can  process 
data  at  disk  transfer  rates.  An  optional  taps  control 
aodule  supports  up  to  eight  tape  drives,  which  can  be  used 
for  direct  disk-to-tape  backup,  data  loading,  and  RDM 
software  leading. 

f.  The  host  interface 

The  RDM  and  the  hes^  (s>  communicate  via  the  host 
interface  aodule.  This  aodule  accepts  commands  from  one  or 
more  hosts,  perforas  error  checking,  causes  *he  host  tc 
retransmit  if  an  error  is  detected,  and  informs  the  database 
processor  that  it  is  moving  a  command  into  the  cache.  Each 
hest  interface  module  can  handle  up  to  eight  hosts.  Hence, 
with  the  full  8  interface  modules,  a  maximum  of  64  hosts  can 
bs  acccaodated  by  the  RDM.  The  standard  interface  module 
supports  both  SS-232  serial  interface  or  an  IEEE-488 
parallel  interface. 
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II.  2IE  J21I£B£SE 


In  oar  benchmark  measures  on  the  BDfl-1100,  it  is  impor¬ 
tant  to  model  the  queries  or  transactions  to  be  processed, 
and  tc  acdal  the  database.  The  performance  of  ar.y  database 
systea  depends  not  only  on  the  characteristics  of  ‘he  data¬ 
base  systea,  but  also  on  the  size  and  s-ructure  of  rhe 
database.  Considering  this  two-dimensional  problem,  we  want 
to  build  databases  where  the  values  for  each  attribute  aay 
be  selected  ftoa  well-defined  domains,  in  addition,  we  feel 
that  these  values  should  have  specified  and  well-formed 
distributions  to  aid  in  the  prediction  of  the  response  set 
for  any  given  query. 

He  have  built  a  paras eterized  relation  generator,  a 
software  system  to  generate  relations  for  synthetic  data¬ 
bases.  These  synthetic  databases  are  then  used  by  our  query 
stream  tc  simulate  the  activity  of  actual  users  on  the 
sytea.  Several  of  these  databases  are  built,  varying  the 
tuple  widths  as  well  as  the  number  of  tuples  per  relation. 
Ha  then  attempt  to  distribute  the  databases  on  the  disks  tc 
force  specific  actions  on  the  processor,  such  as  Icin  opera¬ 
tions  between  relations  on  the  same  or  seperate  disks.  Tn 
this  manner  we  seek  to  find  any  significant  difference  due 
to  the  distribution  and  location  of  the  data  on  disks. 

1.  THI  USE  OF  SYNTHETIC  D1TA 

As  with  any  system  model,  it  is  important  that  the 
synthetic  data  adequately  represent  the  essential  character¬ 
istics  cf  real  databases.  By  utilizing  the  synthetic 
database,  we  can  represent  a  subset  of  the  real- world  data¬ 
base  and  save  tiae  and  space  for  not  accommodating  the  full 


set  cf  the  real-world  database.  However,  the  organization 
is  general  enough  to  provide  an  emulation  cf  the  real  world. 
The  synthetic  databases  we  have  designed  includ  the  basic 
data  types  that  would  exist  in  a  real-world  database: 
integer,  character,  and  so  on.  For  attribute  values  we  have 
incorporated  both  sequential  and  randoa  orders,  as  well  as 
groupings  according  to  specific  discrete  distributions. 
These  are  sore  fully  described  in  the  next  section.  Using 
this  forsat  we  can  not  only  accurately  predict  the  outcome, 
i.e.  amounts  of  data  returned  by  a  query,  but  we  can  also 
easily  reproduce  the  databases  cn  other  systems  for  further 
tests. 

B.  GEHEB1TI0H  OF  THE  SYNTHESIZED  DATA 

When  designing  the  database,  our  first  concern  is  with 
the  physical  sizes  that  should  be  used.  The  relations  must 
be  large  enough  to  test  the  full  capacity  of  the  system, 
and  meaningful  enough  to  include  various  attributes.  For 
example,  we  choose  tuple  widths  of  100,  200,  1000,  and  2000 
bytes  with  the  maxicum  tuple  width  being  limited  at  2000 
bytes  and  the  dish  access  being  performed  in  2k  blocks. 

Our  second  consideration  is  how  large  the  relations 
should  be,  i.e.,  how  many  tuples  per  relation.  Again,  in 
crder  to  test  the  system  for  both  large  and  small  relations, 
we  decide  on  relations  with  500,  1000,  2500,  5000,  or  10000 
tuples.  These  are  arbitrary  decisions.  The  relation  sizes 
are  multiples  of  the  smallest  number  in  order  to  facilitate 
comparisons  cf  the  test  results. 

Our  next  consideration  is  the  actual  design  and  building 
of  the  data  generation  tool,  He  envision  a  great  many  data¬ 
bases  with  differing  configurations.  Thus,  an  interactive 
interface  tc  a  generation  program  appears  to  be  the  most 
effective  approach.  Osing  the  locally  available  IBM  3033 
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TH/C  as  installation  and  P&SCAL/TS  as  the  language,  an  inter- 
actiT«  system  is  built.  Foe  sore  inferaation  cn  the  design, 
progressing,  and  operation  of  this  tool,  please  see 

[lef .  6]. 

Using  the  interactive  systea,  the  user  is  allowed  to 
define  the  forsat  cf  a  relation  in  response  to  sytem 
prospts,  on  an  attribute- by-attribute  basis.  The  tuple 
width  and  relation  size  are  defined.  The  user  is  then 
allowed  to  'add'  attributes  to  the  tuples  one  after  another 
until  he  readies  the  desired  liait. 

The  user  can  choose  froa  several  aethods  of  attribute 
value  generation.  Integer  values  can  be  sequential  or 
randoa  within  a  specified  doaain.  Uniqueness  of  the  randon 
integer  can  be  assured.  The  integer  can  be  either  one,  two, 
cr  feur  bytes.  Character-strings  can  also  be  chosen,  either 
ccapressed  cr  uncoapressed,  in  a  collating  sequence  or  in 
soae  randca  order.  Character  string  values  can  also  be 
selected  froa  enuaerated  doaains  either  randcaly  or 
according  to  a  specific  discrete  distribution.  In  our 
prototype  the  discrete  distributions  are  limited  tc  multi¬ 
ples  cf  59.  The  user  is  also  given  the  opportunity  to  set 
the  naaing  convention  for  each  relation  and  its  attributes. 
The  prototype  is  designed  and  iipleaented  with  &  limited  set 
of  alternatives.  It  is  however  modular  for  adding  alterna¬ 
tives  to  the  prototype,  such  as  exponential  or  norsal 
distributions. 

He  use  a  standard  teaplate  for  each  tuple  width.  K 
portion  cf  this  teaplate  is  standard  for  each  relation  (  see 
Figure  2.1  ).  Each  relation  contains:  a  sequential-integer 
attribute,  a  4-byte-in teger, 'Key* ;  a  character-attribute 
'airrer',  which  is  identical  in  numerical  value  to  'key'  but 
stored  as  a  character  string  and  not  as  an  integer;  a 
.  randoa- integer-attribute  'rand’  of  4-byte  integers;  and  a 
character-etring-attribute  'chars',  which  contains 
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Figure  2. 1  Tuple  Templates. 
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characters  in  a  collating  sequence.  The  number  cf  charac¬ 
ters  in  'chers'  is  dependent  on  the  tuple  width,  in  order  to 
ensure  that  tuples  are  exactly  100,  200,  1000,  and  2000 
bytes  wide.  The  length  of  'chars*  is  set  to  the  precise 
number  of  characters  required  to  ensure  that  the  ■‘•upie  is  of 
the  proper  width.  The  randoe  field  is  present  to  aid  in 
randomizing  the  order  of  the  tuples  and  the  purpose  of  the 
mirrcr  field  is  to  compare  the  performance  cf  identical 
retrieve  operations  based  on  queries  qualified  cn  the 
sequential-integer-attribut e,  'key ',  and  the  character- 
attribute,  'mirror'.  The  100-byte  and  200-byte  tuples  also 
contain  a  sequential-unit-letter  field  of  1-byte  character 
in  collating  sequence,  'letter1,  and  a  unique 
randoe- integer-attribute  of  4-byte  integers,  'uniqrand'. 

Each  template  is  then  filled  out  with  attributes  for 
which  the  values  are  chosen  from  a  number  of  enumerated 
values.  Por  example,  the  P10  attribute  specifies  attribute 
valuem  with  a  uniform  distribution  over  ten  unique  values, 
ft  retrieve  statement  with  one  qualifier  could  then  be 
written  tc  retrieve  10^  of  the  tuples  in  the  relation.  The 
number  of  such  fields  is  dependent  cn  the  tuple  width. 

Once  the  design  cf  the  databases  is  complete,  multiple 
instances  of  each  relation  are  built  using  the  interactive 
generation  tool  on  the  IBB  3033.  The  relations  are  then 
transferred  to  tape  storage  for  transport  to  Pt.  Muqu  and 
the  OHIVftC  1100.  The  data  is  loaded  onto  the  UHIVftC  1100 
disks  and  then  loaded  to  the  backend  database  machine  using 
a  bulk-load  utility. 

Teste  are  planned  on  the  basis  of  an  assumed  capability 
to  ccntrcl  the  distribution  of  the  data  on  the  ROB  1 100 
disks.  The  capability  to  direct  a  relation  to  a  specific 
disk  is  net  implemented,  although  the  space  allocation  for  a 
database  car.  be  split  across  multiple  disks.  The  pattern  of 
block  allocation  for  relations  within  the  database  is  cont- 

I 

rolled  within  the  database  machine,  and  is  not  predictable. 


III.  MS  flSISX  LAIGUAGB 


The  interaction  between  the  user  and  -.he  RDM- 1100  is 
through  the  software  interface,  RQL  (relational  query 
language),  provided  by  Aaperif.  The  interface  translates 
the  user  *  s  RQL  command  into  the  backend-machine's  internal 
format  and  sends  the  foraatted  coaaand  to  the  RCM-1100. 
The  software  requirement  for  the  host  is  minimal,  and  the 
backend  eachine  is  Independent  of  the  host. 

When  performing  the  test  runs,  the  test  queries  are 
grouped  into  run-streaas  in  crder  to  make  aor -  efficien*  use 
of  the  available  time.  The  tiae  provided  for  our  test  runs 
has  been  very  restricted.  Since  we  prefer  to  make  our  test 
runs  in  a  stand-alone,  single  user  environment  to  minimize 
the  host  workload  variability,  we  ara  forced  to  execute  cur 
run  streams  during  the  evenings  and  on  weekends.  In  addi¬ 
tion  we  want  to  run  sets  of  tests  over  several  system 
configurations.  This  again  reduces  the  overall  time  for  us 
to  run  cur  performance  tests  on  each  configuration. 

Additional  constraints  are  imposed  by  the  nature  of  the 
interface  software  provided  by  Amperif  and  by  the  configura¬ 
tion  cf  the  machine  at  Pt.  Mugu.  Pre-compilation  of  the 
queries  is  not  supported.  We  therefore  have  chosen  tc  use 
the  stored-commands  facility  of  the  backend  machine  to 
reduce  varability  in  the  parsing  tiae.  The  stored-commands 
facility  allows  the  user  to  store  the  parse-trees  produced 
by  the  interpreter  as  named  commands  in  a  relation  in  the 
user's  database.  When  these  stored  commands  are  invoked  at 
a  later  tiae,  the  parsing  is  reduced  to  a  minimum.  Using 
the  stored-coaaand  facility  also  eliminates  the  time 
required  to  look  up  target- list  and  qualification  a- tributes 
in  the  data  dictionary. 


A.  SIXTH  AXD  SEMANTICS 


The  fcasic  operations  involved  in  retrieving  data  in  a 
relational  systee  are  selection,  projection  and  ioin.  This 
section  will  provide  a  basic  overview  of  the  syntax  of  the 
Relational  Query  Language  (RQL)  ,  with  pertinent  examples. 
For  a  more  detailed  explanation  of  the  language  as  well  as 
the  database  adainstrator  functions,  please  refer  to 
[Ref.  5].  This  thesis  focuses  exclusively  or.  the  selec-ion 
and  projection  operations.  The  interested  reader  is  encour¬ 
aged  to  read  [Ref.  4],  for  an  explanation  and  evaluation  of 
the  join  operations  as  performed  on  the  RDM- 1100  and  its 
various  configurations. 

Simple  selection  in  SQL  is  expressed  as  fellows: 

RETRIEVE  (  A.  ALL  )  WHERE  A.  CITY  =  "CHICAGO" 

The  keyword  to  the  selection  operation  is  RETRIEVE.  The 
relation  referred  to  in  this  case  is  A  and  the  qualifier  ALL 
indicates  that  all  attribute  values,  i.e.  the  entire  tuple, 
are  to  be  returned  for  each  qualifying  tuple.  In  this 
example  an  optional  qualifier  consisting  of  a  single  predi¬ 
cate  has  been  added,  WHERE  A. CITY  *  "CHICAGO".  This 
qualifier  restricts  the  tuples  returned  to  only  those  tuples 
in  which  the  city  attribute  has  a  value  of  "CHICAGO".  The 
qualifier  could  have  multiple  predicates,  related  by  any  of 
the  boolean  operators,  such  as  AND,  05,  *  (EQUAL),  !=  (HOT 

EQUAL),  etc.  An  example  is: 

RETRIEVE  (A.  ALL)  WHERE  A.CITY  =  "CHICAGO"  OR  A.  CITY="MCNT2REY" 


In  this  cas a  the  backend  machine  will  return  all  the  tuples 
in  the  relation  A  in  which  the  city  attribute  has  either  the 
value  "CHICAGO"  or  the  value  "MONTEREY" . 

The  selection  operation  restricts  the  tuples  to  be 
returned.  The  projection  operation  restricts  the  attribute 
values  of  a  tuple:  only  a  portion  of  the  attribute  values  of 
each  tuple  are  returned.  For  example: 

RETRIEVE  (A. CITY,  A. NAME) 

In  this  case,  the  target  list  (A. CITY, 1. NAME)  ,  specifies  the 
attribute  values  to  be  projected  out  of  the  tuple  and 
returned  to  the  user.  Only  the  values  of  attributes  CITY 
and  NAME  for  each  of  the  tuples  in  the  relation  A  will  be 
returned.  A  qualifier  (not  shown)  could  be  added  as  in  a 
previous  example  to  limit  the  number  of  tuples  returned  to  a 
specific  subset  of  the  relation. 

Commands  like  these  make  up  the  bulk  of  the  queries  used 
in  the  selection  and  projection  tests,  with  varying  quali¬ 
fiers  attached.  RQL  has  many  more  capabilities,  such  as  the 
aggregate  functions  and  the  BY  clause.  For  further  details, 
again  refer  to  [Ref.  5], 

B.  TBST  QUERIES 

The  test  querias  used  are  all  selection  and  projection 
operations  in  the  form  of  the  previous  two  examples. 
Qualifications  ar9  used  on  these  queries  to  select  given 
percentages  of  the  attribute  values,  as  well  as  given 
percentages  of  the  tuples  in  each  relation.  As  described  in 
Chapter  II,  single  qualifiers  are  used  on  the  attribute 
values  having  discrete  distributions  to  select  only  a  giver, 
percentage  of  each  relation.  Comparisons  are  made  on  the 


backend  database  machine’s  performance  as  the  percentage  cf 
data  retrieved  is  varied.  This  variation  covers  two  dimen¬ 
sions:  the  percentage  of  tuples  in  a  relation  and  the 

percentage  of  attribute  values  in  a  tuple.  additional 
testing  is  dene  on  single-tuple  retrieves  and  queries  using 
range  predicates  on  the  key  field.  Each  of  these  experi¬ 
ments  is  described  in  further  detail  in  Chapers  IV  and  V 
along  with  a  detailed  description  of  the  commands  used  to 
retrieve  the  data. 

1  •  limiter  Considerations 

As  mentioned  before,  the  most  critical  restriction 
placed  on  the  performance  tests  is  the  lack  of  measurement 
tools.  There  are  no  monitors  available  to  keep  track  of  CPO 
or  I/C  activities  in  the  backend  database  machine.  The  only 
available  measurement  capability  is  a  measurement  of  elapsed 
time  that  cculd  be  extracted  from  the  backer d  database 
machine  clock,  which  has  a  resolution  of  1/60th  cf  a  second. 
Our  prime  concern  in  this  performance  evaluation  is  to 
determine  the  effects  cf  varying  certain  parameters  on  a 
backend  database  machine  and  gather  some  gross  overall 
measures.  In  this  sense,  therefore,  we  feel  tha*  the  rough 
measurements  afforded  by  the  backend  machine  are  still 
acceptable  fer  our  purpose. 

In  erder  to  determine  the  elapsed  time  in  processing 

a  query,  a  retrieve  command  to  extract  the  time  from  the 

backend  database  machine  clock  is  executed  before  ar.d  after 
each  query.  The  retrieve  command  is  of  the  form: 

EETBIE VE  (TIME  =  GETTIMEO)  GO 

GETTIBE  is  a  system  function  of  the  backend  machine.  This 

command  is  used  to  print  a  time,  in  1/60  second  increments. 
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before  and  after  our  queries.  Using  this  throughout  our 
experiments  ve  can  get  gross,  yet  consistent  measure men'-s  of 
total  tine  required  to  execute  the  queries.  Ever,  wi-h  thi  = 
poor  resolution,  the  comparison  of  identical  queries  will 
yield  relevent  performance  comparisons  of  the  response  time 
of  the  backend  machine. 

2 .  Objectives 

The  final  objective  of  these  tests  is  not  to 
generate  large  volumes  of  data  with  figures  c?  retrieval 
times  for  particular  queries.  Our  primary  goal  is  to  make 
relevent  comparisons  of  the  machine  performance  as  the 
gueries  are  varied  inside  specific  parameters.  To  this  end 
we  hope  to  make  some  judgements  of  the  overall  performance 
of  this  particular  backend  database  machine,  but  more  impor¬ 
tantly  tc  gain  some  insight  into  the  testing  methodology  for 
backend  database  machines  in  general.  In  the  next  chapters, 
examples  of  the  run-streams  used  in  the  experiments  are 
given  alcng  with  graphical  representations  of  the  test 
results. 


If.  PEBF0BH1SCE  EVALUATION  Qf  THE  SELECTION  OPERATION 


A.  CEFI1ITIOH  OF  A  SE1ECTI  OH 


Selection  is  a  means  for  the  user  to  retrieve  and 


exaaice  pertinent  infcraation  froa  a  relation.  The  user  may 
select  the  entire  relation  or  he  aay  restrict  the  informa¬ 
tion  returned  to  him  in  two  ways.  He  may  limit  the  number 
of  tuples  returned  by  adding  a  qualification  to  the  selec¬ 
tion  operation.  The  qualification  will  limit  the  tuples 
retrieved  to  those  whose  attribute  values  satisfy  the  condi¬ 
tions  of  the  qualification.  Qualification  consists  of 
predicates,  assertions  on  the  attribute  values  of  the  tuple 
cr  tuples.  Multiple  predicates  aay  be  combined  with  boolean 
operators,  such  as  AND,  OB,  EQUAL,  HOT  EQUAL,  etc.  The  user 
■ay  also  restrict  the  attribute  values  returned  by  expli¬ 
citly  listing  those  attributes  which  he  desires,  a 
projection  of  the  relation.  This  is  further  described  in 
the  following  sections  of  this  chapter. 


B.  SELECTIONS  IN  THE  QUEST  LANGUAGE 


In  BQL  the  user  is  given  consideraole  power  of  selection 
through  use  of  the  RETRIEVE  command.  Using  she  100-byte 
relation  described  in  Table  2.1  as  a  format  for  a  relation 
A,  a  typical  BQL  selection  command  might  be: 


RETRIEVE  (  A.  ALL  )  WHERE  A.  KEY  *  25 


In  this  command  the  keyword  RETRIEVE  is  used  to  signify 
selection,  the  A.  ALL  indicates  that  all  attribute  values 
i.e.,  entire  tuples,  are  to  be  returned,  and  the  keyword 
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WHBBE  identifies  the  quantifier.  The  A. ALL  may  be  replaced 
with  an  explicit  listing  of  those  attributes  desired.  The 
attributes  say  be  listed  in  any  order  the  user  desires. 
Using  the  key  word  BHZBE  and  a  qualification,  the  user  may 
then  indicate  which  cf  the  tuples  ar9  to  be  returned.  Ir. 
this  exatple,  only  those  in  which  the  KEY  field  is  equal  to 
25  are  returned.  The  user  may  use  other  operators  such  as  < 
cr  >,  and  is  given  the  option  to  use  more  than  one  predi¬ 
cate.  For  example: 

BETBIEVE  (  A.  ALL)  WHE8E  A. KEY  >  25  AYD  A. KEY  <  100 

would  return  all  tuples  with  the  KEY  field  in  the  range  26 
through  99.  The  user  *’ s  given  great  latitude  in  delimiting 
the  subset  cf  the  relation  he  desires.  For  more  detailed 
information  concerning  the  capabilities  and  syntax,  the 
reader  is  encouraged  to  read  £Bmf.  5]. 

C.  il  EBVIROHHEHT  FOB  THE  BE&SOBEHEITS 

The  results  discussed  in  this  chapter  are  from  tests 
performed  or  the  system  configuration  with  2-megabyte  cache 
memory  and  the  optional  accelerator.  Lack  of  time  prevented 
a  significant  number  of  tests  on  alternate  configurations 
for  ccmparison.  However,  these  tests  can  be  conducted  on 
ether  configurations  without  modifications. 

As  described  in  Chapter  III,  the  timing  measurements  are 
the  backend  system*  s  response  to  a  retrieve  for  its  internal 
system  clock  time  in  1/60-second  resolution.  In  most  cases 
the  measurements  are  based  on  single  queries  due  to  the  time 
involved.  Some  measurements  are  averages  ever  several  query 
responses;  these  are  differentiated  in  the  sections  which 
follow.  In  all  cases  the  tests  are  runs  performed  in  the 


evenings  and  weekends  with  virtually  no  other  users  or.  the 

sytea . 

D.  SILBCIICH  HB  ASUHBHEHTS 

The  figures  in  the  first  section  represent  results  gath¬ 
ered  for  selections  with  and  without  indicias.  The  number 
of  tuples  returned  is  restricted  to  a  fixed  proportion  of 
the  total  nueber  of  tuples  in  the  relation;  nc  projection  is 
involved.  The  final  sections  give  comparisons  of  the  system 
ordering  capabilities  on  the  frontend  as  well  as  the 
backend,  and  the  effects  of  data  compression. 

1  •  5 he  Percentage  o  f  S election 

Figures  4.1  and  4.2  show  the  system  response  tine 
for  selection.  Figure  4.1  shows  measurements  on  a  database 
with  no  indides;  Figure  4.2  shows  measurements  on  a  data¬ 
base  with  a  non-clustered  index  on  the  P5  and  P10 
attributes.  As  described  in  Chapter  II,  the  P5  and  P10 
attributes  are  attributes  whose  values  are  in  a  uniform 
distribution  over  the  corresponding  percentage.  The  P5 
attribute  values  will  be  20  unique  values  each  appearing  in 
5%  of  the  tuples  and  the  P10  values  are  10  unique  values 
each  appearing  in  lOf  of  the  tuples.  The  queries  used  are 
gualified  on  the  P5  attribute.  Therefore,  fcr  each  query 
the  system  will  return  exactly  5%  of  the  tuples  in  the 
relation. 

As  evident  in  Figure  4.1  the  system  response  time 
increases  nearly  linearly  as  the  amount  of  data  returned 
increases.  As  expected,  the  larger  is  the  tuple  size;  the 
steeper  is  the  slope,  since  the  volume  of  the  data  increases 
sore  rapidly  for  the  larger  tuple  size. 
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Figure  4.2  5%-Selects  with  Non-Clustered  Index  on  P5  and  P10 


Figure  4.2  shews  the  results  of  the  same  queries  rur. 
against  a  database  with  indicies  on  the  P5  and  P10  a^-ri- 
butes.  Comparing  Figurs  4.2  and  4.1,  we  notice  *hat  the 
overall  times  are  greatly  reduced.  The  graph  stall  shews 
nearly  linear  relationship  of  the  increasing  response 
and  of  the  increasing  volume  of  data.  Further  discussions 
cf  the  effects  of  indicies  follow  in  the  next  section. 

The  linearity  of  the  response  time  appears  to  indi¬ 
cate  that  the  systea  performance  is  bound  by  the  speed  of 
the  channel  between  the  host  and  the  backend.  The  larger 
the  veluae  of  data  is  to  be  returned;  the  longer  the  channel 
will  te  active  in  order  to  transfer  the  data. 

2.  Effects  of  Clustered  and  Son-Clustered  Indicies 

The  RDH-1100  supports  two  types  of  indicies,  clus¬ 
tered  and  ncn-clustered.  Creating  a  clustered  index  causes 
the  tuples  to  be  ordered  by  KEY  for  storage,  A  sparse  index 
containing  cn9  entry  per  block  is  built.  k  r. on-clustered 
index,  on  the  other  hand,  contains  a  unique  entry  for  each 
tuple  in  the  relation.  So  ordering  of  tuples  within  the 
relation  is  iaplied. 

Figure  4.3  shows  response  tiaes  for  the  retrieval 
query  with  no  qualification,  but  with  an  ordering  specifica¬ 
tion.  The  queries  are  of  the  fora; 

RETRIEVE  (A.  ALL)  ORDER  3Y  A.  KEY 

where  A  is  the  relation  name  and  KEY  is  an  attribute  in  A. 
In  an  ordered  retrieve,  the  tuples  are  sorted  in  the  backend 
machine  and  then  sent  to  the  host  for  display.  similar 
queries  are  run  against  a  relation  with  no  index,  a  relation 
with  a  ncn-clustered  index  on  the  KEY  attribute,  and  a  rela¬ 
tion  with  a  clustered  index  on  the  KEY  attribute.  The 
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response  times  are  similar  throughout  the  range  of  relation 
sizes.  The  indicias,  clustered  or  non-clustered,  provide  re 
significant  improvement  for  this,  range  of  relation  sizes. 
Tha  expected  results  would  have  shown  a  significant  improve¬ 
ment  for  tha  relation  with  a  clustered  index.  The 
similarity  in  rasponse  times  aay  indicate  that  the  RDM  sorts 
the  tha  tuples,  even  though  the  tuples  have  been  in  sorted 
order  due  to  the  use  of  a  clustered  index  on  the  ordering 
attribute. 

Figure  4.4  shows  the  results  of  test  runs  cn  rela¬ 
tions  with  and  without  non-clustered  indicias  on  the  P5  and 
P10  attributes.  The  graph  shows  a  significant  improvement 
in  response  times  for  the  relations  with  th»  non-clustered 
index,  locking  at  Figure  4.5,  the  improvement  ratio  is  mad? 
more  evident  for  simply  qualified  retrieves  when  the  index 
is  on  the  attributes  used  in  the  predicates  cf  the  qualifi¬ 
cation.  The  larger  is  the  tuple  size;  the  greater  becomes 
the  iaprcveeent.  The  200 -byte  tuple  shows  a  nearly  95*. 
increase  in  the  response  tine.  Phe  other  tuple  sizes  show 
similar  improvements. 

3.  Bffects  of  Data  Compression  on  selection  Queries 


$ 
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Th9  backend  database  machine  has  the  capability  of 
storing  character  strings  in  either  compressed  or  uncom¬ 
pressed  format.  A  character  string  in  compressed  format  is 
stored  on  the  disk  with  no  trailing  blanks.  The  advantage 
is  a  savings  in  disk  space.  The  tradeoff  is  the  increased 
CFO  time  required  to  compress  and  uncompress  the  strings  as 
data  is  moved  to  and  from  the  disk.  Figure  4.6  shews  the 
results  of  test  runs  on  relations  having  only  uncompressed 
attribute  values  and  on  relations  having  only  compressed 
attribute  values.  In  the  initial  test  runs  the  relations 
have  both  compressed  and  uncompressed  attributes  as  speci¬ 
fied  in  Table  2.1,  in  order  to  ensure  the  correct  byte-width 
of  the  tuple. 
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Figure  4.4  Retrieves  with  and  without  Indicies 
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Figure  a. 6  Effects  of  Data  Compression 


More  specifically.  Figure  4.6  shews  th'5  results  of 
the  tes~s  for  the  relations  of  100-byoe  tuple  siz*  and  she 
2000-byte  tuple  size,  respectively.  For  the  100-byts  tuple 
the  storage  requirement  is  reduced  by  approximately  SO1?  when 
all  attributes  are  fully  compressed.  In  the  case  of  ‘hs 
2000-byte  tuple  size,  the  savings  in  storage  is 
approximately  90X. 

The  graph  shews  a  major  improvement  in  the  response 
time  fer  compressed  relations.  From  the  steep  slope  of  the 
line  it  appears  evident  that  the  greatest  impact  on  system 
speed  is  the  amount  of  data  that  must  pass  over  the  internal 
bus.  The  large  reductions  in  tuple  size  for  the  compressed 
relation  shews  a  clear  advantage  over  the  uncompressed  rela¬ 
tion.  The  delay  becomes  increasingly  significant  for 
relations  of  larger  tuple  sizes.  Approximately,  a  delay 
factor  of  10  for  the  larger  tuple  size  and  10000-tuple  rela¬ 
tion  is  observable. 

4 .  Effects  of  Ordering  and  Randomizing  the  Database 

2°£^£s 

Figure  4.7  shews  the  rssulrs  of  tests  to  measure  the 
backend  system’s  sorting  capabilities.  The  relations  used 
are  stored  in  the  backend;  their  tuples  are  ordered  on  their 
KEY  attributes.  The  graph  depicts  retrieves  with  and 
without  ordering  specifications  on  the  KEY  ar tribute.  There 
is  a  slight  increase  in  the  response  time  for  the  ordered 
retrieves,  as  might  be  expected.  The  differential  line 
depicts  the  extra  time  necessary  for  the  ordering,  which 
increases  as  the  relation  size  increases. 

Figure  4.8  shews  the  cost  of  performing  the  ordering 
on  the  backend  versus  the  host.  In  this  case  batch  runs  on 
the  hest  are  used  to  perform  the  queries.  In  general,  “he 
batch  retrieves  show  a  marked  improvement  in  response  time 
for  identical  queries  over  the  run-stream  queries  used  in 
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Figure  4.7  Effects  of  Ordering  on  the  Response  Tiie 


Figure  4.8  k  Comparison  of  Host*s  and  Backend*s  Ordering  Capability 


Figure  4.7.  This  say  b»  due  tc  the  decreased  overhead  cost 
for  batch  versus  an  interactive  environment .  Figure  4.8 
also  sheas  that  for  smaller-size  relations  the  backend 
performs  a  aore  efficient  ordering  than  the  host  does.  Even 
for  larger  relations  the  sort  time  of  the  host  and  the  scr+ 
time  cf  the  backend  are  comparable. 

Finally#  Figure  4.9  shows  the  effect  cf  randomizing 
the  order  of  the  tuples  in  the  relation.  Dsing  the  random- 
number  attribute  to  scatter  the  tuples  in  the  relation, 
similar  retrieves  are  performed  on  the  ordered  and  random¬ 
ized  relations.  In  this  case  there  is  a  non-clustered  index 
on  the  KIT  attribute  for  the  relations.  The  graph  shews 
minor  variances  in  response  times  betwaen  the  two#  clearly 
indicating  that  the  erder  in  which  tha  tuples  are  stored  is 
not  a  significant  factor  in  response  time  for  the  ordered 
retrieves. 

B.  CONCLUSIONS 

The  response  times  are  generally  linear,  increasing  as 
the  amount  of  data  tc  be  returned  is  increasing.  The  amount 
cf  data  may  be  varied  as  the  number  of  tuples  in  a  relation 
or  the  width  of  the  tuples. 

Tha  creation  of  indicies  on  tuples  shows  significant 
improvement  in  response  times  when  the  retrieve  command  is 
qualified  on  the  indexed  attributes.  The  indicies  provide 
marked  improvement  as  tha  tuple  size  increases. 

The  effects  of  data  compression  shows  some  interesting 
results.  Figure  4.6  has  shewn  a  very  large  improvement  for 
compressed  tuples.  This  improvement  is  most  likely  attribu¬ 
table  tc  the  decrease  in  the  number  of  disk  blocks  accessed. 
In  fact#  the  difference  in  time  is  proportional  to  the 
decrease  in  the  number  of  blocks  used  for  the  tuples. 


Effects  of  Ordering  on  Ordered  and  Bandoa  Relations 


Finally,  the  ordering  test  shows  that  -he  backend  oa 
sort  tUFl«3  at  least  as  fast  as  the  host  car..  Naturally 
the  major  portion  of  the  time  is  spent  in  transferring  th 
data  frca  the  disk  tc  either  the  host  or  the  backer.  1;  but 
nevertheless,  the  tacker.d  proves  more  efficient  for  -h 
smaller  size  of  relations. 


V.  flJIfigaiSCI  IVALUAT ION  OF  PROJECTION  OPERATION 


1.  DEFINITION  OF  A  PROJECTION 

Projection  is  a  means  to  restrict  the  amount  and  to 
order  the  sequence  of  information  returned  to  the  user  in  a 
retrieval  operation.  Bore  specifically,  projection  will 
restrict  the  attribute  values  that  will  be  returned  from 
each  tuple  selected.  Projection  and  selection  can  be 
combined  to  limit  the  range  of  values  returned.  In  addi¬ 
tion,  a  user  can  rearrange  the  ordering  of  the  attribute 
values  as  the  relation  is  displayed  by  varying  the  order  of 
the  attribute  names  in  the  target  list.  This  is  not  to  say 
that  the  actual  order  of  the  stored  relation  is  altered  but 
that  the  subset  displayed  to  the  user  is  ordered  according 
to  him  specifications. 

B.  PROJECTIONS  II  TEE  QUEHI  LANGUAGE 

In  RCL  the  user  is  given  considerable  latitude  to 
describe  precisely  which  attribute  values  that  he  wants  to 
be  returned.  Using  the  100-byte  relation  described  in  Table 
2.1  as  a  fcrmat  for  a  relation  A,  the  SQL  command: 

RETRIEVE  (  A. KEY , A. HIRRCR  ) 

will  return  to  the  user  only  those  attribute  values  in  the 
relation  A  whose  attribute  names  are  KET  and  HIRROR.  The 
user  can  list  as  many  attribute  names  as  he  desires  and 
place  thee  in  any  order  in  the  target  list  of  the  RETRIEVE 
command.  In  the  case  where  all  attribute  values  of  a  rela¬ 
tion  are  to  be  listed,  the  user  may  simply  use  A.  ALL.  All 
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attribute  values,  i.e.,  satire  tuples,  will  be  rs-urr. =d  i~ 
order  as  they  art  stored.  The  user  can  also  add  qualifiers 
to  restrict  the  nuaber  of  tuples  returned.  These  qualifiers 
need  not  he  on  the  attributes  listed.  For  example, 

RETRIEVE  (  A.KBT,A.HIRROR  )  WHERE  A.P5  »  MRED" 

will  again  return  to  the  user  only  those  attribute  values  in 
the  relation  k  whose  attribute  naaes  are  RET  and  MIRROR.  In 
addition,  the  qualifier  will  restrict  the  tuples  returned  to 
those  whose  ?5  attribute  value  is  RED.  This  RETRIEVE 
ooaaand  also  illustrates  the  aeans  to  perforin  a  percentage 
selection.  The  P5  attribute  values  are  colors  selected  from 
an  enuaerated  set.  Each  different  color  value  it  the  ?5 
attribute  is  present  in  5%  of  the  tuples  in  the  k  relation. 
Using  these  known  percentages,  the  P5  qualification  will 
select  exactly  5*  of  the  tuples  in  relation  A. 

C.  il  E1VI  BOTH  BUT  FOR  THE  HEASUBEHEITS 

The  projection  aeasureaents  discussed  here  are  all  on 
the  sane  systea  configuration  with  2-megabyte  cache  memory 
and  the  optional  accelerator.  Lack  of  time  has  prevented  us 
froa  obtaining  aeasureaents  on  other  configurations. 

The  projection  aeasureaents  are  conducted  for  feur  tuple 
sizes,  i.e.  •  100-byte,  200-byte,  1000-byte,  and  2300-byte, 
in  three  percentages  of  returns,  25*,  50*,  and  75*.  These 
percentages  refer  to  the  nuaber  of  attribute  values  in  rh« 
tuple  that  is  returned.  With  the  exception  of  che  100-byte 
tuple  size,  these  are  exact  percentages;  in  che  100-byte 
case,  the  nusber  of  attributes  returned  was  29%  and  71%. 
This  is  due  to  the  tuples  in  the  100- byte  relation  having  14 
attributes.  k  strict  percentage  of  25%  and  75%  was  not 
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attainable.  Nevertheless,  they  are  still  referred  tc  as  25* 
and  75%  projections.  Further,  the  retrieval  commands  are 
qualified  by  5%  and  10%  selections  in  order  tc  reduce 
further  the  aaount  cf  data  to  be  returned.  Each  query  is 
executed  10  tiaes,  each  tiae  with  a  different  qualification. 
This  is  dene  to  eliainate  any  effects  due  to  the  location  of 
the  data  in  the  relation  and  provides  a  better  average 
response  tire. 

0.  PBO JECTI09  H BASH BEHESTS 

The  test  queries  used  are  qualified  on  the  P5  and  P10 
fields  of  the  relation  to  perform  the  aforementioned  selec¬ 
tion.  Each  query  is  th9n  repeated  10  tiaes  with  a  differen- 
qualifier.  The  figures  represent  the  average  response  tiae 
for  those  ten  tests.  Each  graph  shows  the  response  tiae  in 
seconds  plotted  against  the  number  of  tuples  in  the 
relation. 

1.  Percentage  aJ  Projections  on  Non -Rev  Attributes 

In  general  tie  difference  in  response  tiaes  for  the 
five-percent  and  ten-percent  selections  is  negligible,  this 
is  particularly  true  for  the  saaller-size  relations. 
Doubling  the  number  cf  tuples  returned  in  a  query  can  result 
in  approximately  a  20%  increase  (i.e.,  1/3  second  increase 
in  the  response  tiae  cn  the  average)  in  the  smaller  tuples 
and  a  10%  increase  (i.e.,  7  seconds  on  the  average)  in  the 
larger  tuples.  Figures  5.1  and  5.2  show  the  results  of  a 
25%  projection  over  varying  tuple  widths,  with  Figure  5.1 
for  a  5%  selection  and  Figure  5.2  for  a  10%  selection.  As 
can  be  seen,  the  graphs  in  these  two  figures  are  nearly 
identical.  This  is  also  the  case  for  the  graphs  on  the  50% 
and  75%  projections.  For  example,  in  Figures  5.3  and  5.u, 
similar  graphs  for  the  5%  selection  with  50%  and  75% 

47 


megabyte  cache  wfth  accelerator 


25%  Projections  on  10%  Selections 


Figure  5.3  50%  Projections  on  5%  Selections 


pro jections  are  displayed  respectively.  In  each  graph  of 
the  aforementioned  figures  response  times  increase  almost 
linearly  as  the  relation  size  increases,  and  increase 
draaatically  as  the  number  of  attribute  values  returned 

increases. 

Figures  5.5  and  5.6  give  a  differ enr  perspective  on 
the  same  data.  In  this  case  the  rise  fcr  differing  projec¬ 
tion  sizes  is  graphed  over  a  constant  tuple  width.  As 
expected,  the  greater  the  nuaber  of  attribute  values 
returned,  the  larger  the  response  tiae.  Again  a  much 
steeper  slope  is  evident  in  Pigure  5.6  for  the  bigger-width 
tuple. 

2.  Ccs car i son  of  the  5 gui valent  Queries  on  Selection 

Figures  5.7,  5.8,  5.9,  and  5.10  show  the  differences 
in  the  response  tise  as  the  nuaber  of  attribute  values 
returned  per  guery  is  varied.  In  each  graph,  the  tuple  size 
resains  constant.  In  addition  to  the  varied  project ior. 
percentages,  a  fourth  line  representing  a  selection,  in 
which  all  attribute  values  ir.  each  tuple,  (i.  e. ,  the  entire 
tuple)  are  returned,  is  added.  The  test  queries  used  for 
the  line  sarlced  'full  select'  use  the  ALL  specification  to 
return  all  attribute  values  in  each  tuple.  As  in  the 
projection  seasures,  each  such  guery  is  repeated  10  times. 
The  5*  selections  are  done  on  the  P5  field  and  a  different 
value  is  used  in  the  qualifier  for  each  of  the  10  queries. 

As  would  be  expected  each  figure  shows  a  marked 
difference  in  the  response  tiae  as  the  number  of  attribute 
values  returned  is  increased.  The  smaller- width  tuples  in 
Figures  5.7  and  5.8  show  a  nearly  linear  increase  in  the 
response  tiae  as  the  relation  size  (the  number  of  tuples  of 
the  same  tuple  width)  increases,  and  an  increase  in  the 
slope  of  the  line  as  the  projection  size  increases.  In 
Figure  5.7  the  response  tine  for  full  select  is  strictly 


Figure  5.5  Effects  cf  Differing  Projection  Percentages  for  200-byte  Tuples 


Figure  5.6  Effects  cf  Differ 


Figure  5.8  Comparison  of  Projection  and  Selection  for  200-byte  Tuples 


Figure  5.9  Comparison  of  Projection  and  Selection  for  1000-byte  Tuples 
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Figure  5.10  Coaparison  of  Projection  and  Selection  for  2000-byte  Tuples 
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saaller  than  any  projection  tine,  which  indicates  -.hat  for 
the  saaller  tuples  the  backend  does  a  strict  selection  prior 
to  extracting  the  attribute  values  specified  ir.  the  projec¬ 
tion  qualifier.  As  the  tuple  width  increases,  the  full 
select  aay  take  aore  tiae  than  that  of  the  projection.  For 
the  200-byte  tuple  in  Figure  5.8,  the  full  select  tine  is 
again  nearly  linear,  and  the  tiaes  are  slightly  acre  than 
the  tiles  for  a  25*  projection.  The  difference  in  response 
between  the  full  select  and  the  25*  projection  steadily 
increases  as  the  relation  size  increases,  but  even  so  the 
full  select  is  faster  than  the  50*  and  75*  projections. 

For  euch-bigger-width  tuples.  Figures  5.9  and  5.19 
show  that  the  full  select  tiae  is  higher  than  the  projection 
tiae  for  the  saall  percentage  projections.  The  full  select, 
however,  has  a  auch  saaller  slope,  thereby  crossing  the  line 
of  the  projection  tiae  and  eventually  showing  a  trend  of 
quicker  response  as  the  relation  size  increases.  Also  of 
particular  note  is  the  uniforaity  of  the  curves  for  the 
varying  projections  in  the  1000-byte  and  2000 -byte  tuples  in 
Figures  5.9  and  5.10.  In  contrast,  for  the  saaller  tuples 
the  lines  are  nearly  linear  with  increasing  slopes.  The 
lines  for  the  larger  tuples  are  cot  linear  and  the  slopes 
are  very  even. 

1.  coicmsioHS 

In  general,  the  projection  results  are  very  predictable 
in  that  the  response  tine  is  nearly  linear  and  the  response 
tiae  increases  as  tbs  asount  of  data  returned  increases. 
The  asount  cf  data  aay  be  deterained  by  either  the  relation 
size  cr  the  projection  size. 

The  full  select  comparisons  in  Figures  5.7,  5.8,  5.9, 

and  5.10,  on  the  other  hand,  show  sene  unanticipated 
results.  Instead,  of  showing  a  clear  advantage  in  the 
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response  tiae  for  fall  select  in  all  relation  sines,  as 
sight  be  «xpected,  the  results  vary  with  the  tuple  widths. 
In  the  smaller  tuple  width  as  depicted  in  Figure  5.7,  the 
full  select  appears  tc  run  faster  even  though  the  amount  of 
data  returned  is  greater.  For  the  200-byte  tuples  as 
depicted  in  Figure  5.8,  the  relationship  is  markedly  diffe¬ 
rent.  Fcr  the  larger  tuples  as  graphed  in  Figures  5.9  and 
5.10,  the  full  select  requires  aore  tiae  for  *he  smaller 
relations.  Nevertheless,  its  advantage  becomes  evident  as 
the  relation  size  increases.  In  summary,  the  full-select 
operation  is  sensitive  to  the  width  of  the  tuples.  In  ether 
words,  the  greater  is  the  tuple  width;  the  higher  is  *he 
select  tiae.  The  full-select  operation  is  also  sensitive  to 
the  size  of  the  relations,  although  in  an  opposite  way. 
That  is,  the  larger  is  the  relation;  the  smaller  is  the 
select  tiae  in  proportion  tc  the  projection  time. 

It  is  difficult  to  determine  what  effect  fche  cache  and 
accelerator  with  other  configurations  may  play  in  these 
tests.  A  need  exists  for  aore  research  in  this  area  to 
verify  the  figures  and  collect  aore  data  over  a  wider  range 
of  tuple  widths  and  relation  sizes  in  hopes  of  obtaining  a 
clearer  trend  to  the  relationship  of  the  full  select  and  the 
projections  as  the  widths  and  sizes  varies. 
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▼I.  COHCIODIBG  REMARKS 


A.  OVERALL  OBSERVATIONS  OP  TBB  MACHINE  PERFORMANCE 

The  experiments  described  in  Chapters  IV  and  V  show  sene 
predictable  results  as  well  as  sone  unexpected  surprises. 
Generali?  the  sinple  select  operations,  with  or  without 
indicies,  display  expected  trends.  The  response  rime 
increases  as  the  amount  of  data  to  be  returned  to  the  host 
increases,  as  shown  in  Figures  4.1  and  4.5.  A  similar  trend 
is  seen  for  relations  with  compressed  attribute  values.  As 
Figure  4.6  illustrates,  reduction  in  the  response  time  can 
be  significant  for  the  large  tuple  widths  where  the  degree 
of  compression  is  high.  The  relations  with  indicias  also 
show  expected  improvements  in  the  response  time  for 
retrieves  qualified  cn  these  attribute  values. 

Seme  unexpected  results,  however,  are  seen  for  the  test 
results  dealing  with  ordered  retrieves.  Figure  4.8.  The 
backend  shows  an  unexpected  superiority  in  sorting  over  the 
host  for  smaller-size  relations.  Even  for  the  large  rela¬ 
tions,  up  to  10000  tuples,  the  backend  maintains  a  response 
time  comparable  with  the  host.  One  would  expect  that  the 
mainframe  would  have  a  significant  advantage  in  computing 
power  and  show  a  major  improvement  when  the  relation  is 
ordered  in  tbs  host  Instead  of  in  the  backend. 

Another  interesting  result  is  the  effect  of  clustered 
and  scn-clustered  indicies  on  ordered  retrieves.  Creating 
a  clustered  index  on  a  relation  will  cause  the  tuples  to  be 
stored  in  a  specific  order  while  a  non-clustered  index  does 
not  imply  any  ordering  of  the  tuplas.  Figure  4.3  shows  very 
similar  response  times  throughout  the  range  of  relation 
sizes,  regardless  of  whether  the  index  is  clustered  or 


non-clustered.  This  implies  that  the  retrieved  tuples  are 
sorted  even  when  a  clustered  index  exists  for  the  qualifier 
attributes. 

The  tests  concerning  projection  of  tuple  attributes  in 
Chapter  V  again  show  predictable  results.  Through  all  the 
figures  fcr  differing  projection  percentages  and  tuple 
widths,  the  graphs  display  near  linearity  in  both  dimen¬ 
sions.  The  response  time  increases  as  the  tuple  width  or 
the  number  of  tuples  returned  increases.  But  surprising 
results  are  evident  when  comparing  projection  to  full 
selection. 

Consider  Pigures  5.7,  5.8,  5.9,  and  5.10  again.  As 

explained  in  Chapter  P,  the  overlay  of  the  full  select  on 
the  varying  projection  sizes  shows  no  positive  trend.  The 
projection  measurements  are  consistent  throughout  the 
figures,  yet  the  full  selects  relationship  to  the  projec¬ 
tions  varies  from  one  figure  to  the  next.  Two  of  the  four 
figures  indicate  that  it  is  cheaper  to  retrieve  entire 
tuples  than  to  project  attribute  values  from  the  tuple.  One 
figure  indicates  that  beyond  a  fixed  relation  size,  it  is 
cheaper  tc  retrieve  entire  tuples.  The  fourth  figure  seems 
to  indicate  that  some  degree  of  projection  is  always  cheaper 
than  retrieving  the  entire  tuple.  Ho  clear  conclusion  can 
be  drawn.  Bore  tests  over  a  wider  range  of  tuple  widths  are 
required  to  identify  an  overall  trend  or  relationship 
between  projection  percentage  and  the  full  selection 
retrieves. 

B.  DATABASE  AID  BiCHIVE  LI BITATIOHS 

When  considering  the  test  environment,  two  specific 
limitations  stand  above  all  else.  The  first  of  these  is  the 
low  resolution  of  the  clock  from  which  measurements  are 
taken.  The  standardized  use  of  the  GETTIHE  function 


throughout  the  tests  has  made  comparison  of  various  test 
results  over  differing  periods  meaningful.  Sven  so,  the  low 
resolution  makes  the  need  for  average  times  over  many 
similar  test  runs  a  necessity.  This  greatly  limits  the 
amount  of  time  that  one  can  spend  in  running  more  meaningful 
tests  and  in  verifying  previous  results.  &  great  effort  has 
been  made  to  find  some  other  timing  mechanism.  In  the  end, 
GETTIflE  proves  to  be  the  easiest  to  use,  the  most 
consistent,  and,  most  importantly,  the  easiest  to  control. 

The  second  limitation  concerns  the  system  configuration 
and  the  inability  tc  control  the  environment  of  both  the 
host  and  the  backend.  The  performance  of  these  tests  has 
not  been  a  very  high  priority  of  the  parent  command  at  pt. 
Hugu.  This  is  to  be  expected,  since  the  host  machine  is  in 
a  production  environment.  Gaining  exclusive  use  is  very 
difficult  and  extremely  costly.  With  this  restriction,  our 
tests  are  limited  to  weekend  and  evening  runs,  at  times  of 
rmlativmly  low  activity.  This  significantly  reduced  the 
time  cf  system  availibility .  ilso,  in  terms  of  the  environ¬ 
ment,  the  backend  systea  we  used  is  a  relatively  new  piece 
of  equipaent.  Lastly,  the  sytem  configuration  has  beer, 
changing  frequently  during  the  experimentation  period.  The 
time  each  configuration  becomes  available  has  been  short. 
Consequently,  not  enouqh  data  can  be  collected  to  make  any 
significant  comparisons. 

C.  BlCCaaiHD&TIOVS  fOB  POT DIE  BEICHBiBKXIG  EFFORTS 

In  light  of  the  test  results  discussed  here,  the  direc¬ 
tion  of  future  work  should  be  toward  effects  of  various 
indicias  and  ordering  capabilities.  The  results  of  tests  on 
various  types  of  indicias  and  the  ordering  of  relations  show 
the  acmt  startling  results.  In  addition,  soae  work  is 
required  over  a  wider  range  of  tuple  widths  to  refine 
previous  rmmults. 
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Another  aspect  that  warrants  research  is  a  mix  of  rests 
to  simulate  a  more  realistic  system  load,  specifically  tests 
with  multiple  users  cf  the  backend  and  a  more  realistic  host 
workload.  The  tests  in  this  thesis  are  runs  on  an  unloaded 
system.  In  actuality,  the  use  of  the  system  will  most 
likely  occur  closer  to  peak  loading.  Perhaps  different 
trends  may  develop  when  the  host  and/or  backend  are 
subjected  tc  different  load  conditions. 

Even  though  these  tests  are  on  a  specific  system,  they 
are  general  enough  in  nature  to  provide  insight  for  tests  on 
other  relational  machines  and  to  aid  in  making  a  comparison 
cf  different  backends. 
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